Computer networks have grown increasingly complex, employing technologies such as distributed client/server applications, mixed platforms and multiple protocols, all on a single physical backbone. A trend which has added to the abovementioned complexity of the networks is the shifting of traffic control methods on the networks from centralized information system departments to distributed workgroups. Another catalyst of the increased complexity is the growing utilization of computer networks. This growth of utilization is what also makes the operation of computer networks more mission critical for day-to-day business operations.
Computers which are part of a computer network such as the abovementioned networks, communicate with each other by means of protocols based on the Open Systems Interconnection model (“OSI”). The OSI model is an internationally accepted framework of standards for communication between different systems manufactured by different vendors. The OSI model creates an open system networking environment in which any vendor's computer system, connected with any network, can freely share data with any other computer system on that network, or on a linked network. The OSI model defines seven layers of communication with which all devices must comply.
Data transfers between servers and clients in a computer network are performed through switches, routers, or gateways. Routing and switching functions are provided by layers 1 through 3 of the abovementioned OSI model. Layers 4 through 7 of the OSI model deal with end-to-end communications between a source computer sending data (“source”) and a destination computer, which should eventually receive the data (“destination”).
In order to ensure reliable traffic flow between sources and destinations within a network, and from a source in one network to a destination in another network, it is important to provide a testing system for testing the various network components responsible for the proper routing and channeling of traffic within networks and between networks (“system under test” or “SUT” e.g. servers, switches, routers, gateways, systems for wire-speed application layer classification of data packets, and pre-processing of data packets in a full duplex network).
Testing systems are connected with the SUT either directly, or through various network components that are responsible for performing network management functions such as network restoration, customer servicing, circuit testing, and call monitoring, through which nodes the test machines perform their tests.
Most testing systems are implemented on the third layer of the OSI model (the “network layer”). There are also known in the art testing systems that are implemented on the seventh layer of the OSI model (the “application layer”).
The advantage of using application layer testing systems (“ALTS”) is that when running a test which is initiated in the application layer, all other layers participate in the process, and are therefore testable, whereas when using a network layer testing system (“NLTS”) the test sequence begins at the network layer, and therefore only layers 1-3 participate in the testing process.
Application layer testing systems are used for testing of the protocols that provide the actual service sought by an end user of a computer connected to a network, and these protocols can only be tested by means of application layer test machines. These examples of service protocols include hypertext transfer protocol (“HTTP”), file transfer protocol (“FTP”), simple mail transport protocol (“SMTP”), real time streaming protocol (“RSTP”), and others.
In general, for the purpose of testing a SUT, application layer testing systems generate traffic streams, which require the use of the specific protocol being tested (e.g. e-mail messages when the SMTP protocol is being tested). Once generated, these traffic streams are sent to a remote destination in the network for the purpose of testing the network component involved in the process of handling the generated traffic. The traffic streams are routed through the network according to unique network addresses (e.g. IP address).
The test results (i.e. success or failure) are determined according to the feedback returned from the SUT, which is gathered by a monitor program, probing the SUT, and from other network components that took part in handling the generated traffic.
As mentioned hereinabove, currently available test machines provide reports only as to the success or the failure of each test, but they do not provide any additional details regarding the results of the test.
Generally speaking, testing systems are capable of generating two different types of traffic streams, dynamic test traffic, and static test traffic, each by means of a different protocol. For the purpose of sending dynamic traffic testing systems use the transmission control protocol (“TCP”). For the purpose of sending static test traffic the testing system uses the user datagram protocol (“UDP”). Each of these types of test traffic has its own unique properties, as follows:
Static test traffic enables the testing system to send the test traffic at varying traffic rates (i.e. to control the traffic rate, usually measured in bps, of the traffic streams used in the test), but it can not interact with the destination network component, nor with any other network component participating in the channeling of the generated traffic stream. Therefore no acknowledgement information is received from these network components. In addition, even when generating a static traffic stream, the different rates from which a user of the testing system can choose are discrete, rather than continuous (e.g. a user can only choose from the following three traffic rates: 5 bps, 10 bps, or 15 bps). In contrast, a testing system generating a dynamic traffic stream can interact with the destination network component, or with any other network component participating in the channeling of the generated traffic stream, but it cannot control the traffic rate during a test session.
The dynamic characteristics of the dynamic traffic generated by the testing system are generic and inherent to the standard TCP/IP mechanisms, and are not unique to the testing system (i.e. the information regarding the acknowledgment of traffic in the network is automatically generated by the TCP protocol, and is sent from the destination network component, or from any other network component participating in the channeling of the generated traffic stream to the client that generated the stream). These dynamic characteristics does not exist as part of the UDP protocol, which enables control over the traffic rate.
Interacting with the destination network component, or with any other network component participating in the channeling of the generated traffic stream is desirous since it enables retrieving of acknowledgement information regarding the test traffic. Controlling the traffic rate is desirous for the purpose of being able to test the SUT under different loads of traffic.
Currently, no known testing system can generate test traffic which has the characteristics of both the dynamic and the static traffic streams. Moreover, the known dynamic traffic testing systems that generate dynamic traffic don't use the full acknowledgement information received in return, only providing the basic responses of failure or success of a certain test.
Furthermore, no known testing systems are capable of sending test traffic to a large number of servers during a single test session, a property which is desirable for the purpose of testing of vast loads, or for the purpose of testing of more than one protocol in a single test session.
Therefore, there is a need for a testing system capable of generating test traffic that has both dynamic characteristics and static characteristics, and that will further query the full acknowledgement information of the test traffic for more detailed results regarding the acknowledgement of the test traffic (e.g. number of bytes sent, number of packets that were transmitted, and the number of packets that were received, including their serial number etc.), and that is further capable of communicating with more than one destination server during a test session.